enhancement(tag_cardinality_limit): Add per-tag cache_size_per_key override in probabilistic mode#25650
Conversation
3bc46fc to
b845b1c
Compare
9850e50 to
ce0e240
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ce0e240502
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
98dc579 to
657934e
Compare
|
codex generated Mostly yes, but I’d ask for one small follow-up before merging: Finding
Minor polish:
Verification: |
|
Updated PR with requested changes |
@ArunPiduguDD thanks. Please also fix the merge conflicts and I will take a final look. |
…in probabilistic mode
…_key in exact mode
3536cf6 to
2ab0c0f
Compare
@pront Rebased PR & fixed merged conflicts (+signed earlier unsigned commits) |
Summary
In probabilistic mode, the bloom filter cache size (
cache_size_per_key) was a single global/per-metric setting inherited by every tag. However, when specifying a per-tag override, it doesn't really make sense to inherit this value, especially in cases where the per-tag override specifies a much higher limit than the global/per-metric limit.This adds an optional
cache_size_per_keyfield to per-taglimit_overrideentries. When set, it overrides the bloom filter size for that tag only. When omitted, it inherits from the enclosing per-metric or global config as before. Setting it inexactmode causes a validation error.Example:
Vector configuration
See example above. Works in both top-level
per_tag_limitsand insideper_metric_limits.How did you test this PR?
apply_cache_size_overridecovering probabilistic+Some, probabilistic+None, and exact+Some (no-op).per_metric_limitsand globalper_tag_limitsscopes.Change Type
Is this a breaking change?
Does this PR include user facing changes?
no-changeloglabel to this PR.